In a database management system (DBMS), data is stored in one or more data containers. Each container contains records and the data within each record is organized into one or more fields. In a relational database system, the data containers are referred to as tables, the records are referred to as rows, and the fields are referred to as columns. In object oriented databases, the data containers are referred to as object classes, the records are referred to as objects, and the fields are referred to as attributes. Other database architectures may use different terminology. The claims of the present application are not limited to any particular type of data container or database architecture.
Many applications having extensive data handling requirements often rely on an independent DBMS to help manage application data. Such applications may include business applications, including customer relationship management (“CRM”) systems and enterprise resource planning (“ERP”) systems. Using a separate, independent DBMS allows application designers to rely on the DBMS to handle complicated bulk data storage functions, while freeing designers to focus on creating application specific functions. In addition to the division of labor benefit, such a dual system model provides a simple and commonly used security framework where security functionality is localized to the application system. For example, many proprietary business applications, including CRM systems using a DBMS, provide access to CRM data only through the CRM system, thereby ensuring that data access and data security are managed through security functions provided by the CRM application. In this model, it is common for the CRM system to implement a closed, private database instance that can only be accessed from the CRM application or by a system administrator for maintenance purposes.
The security model used in prior art systems is shown in FIG. 2. In this security model, the DBMS is setup to deny general access to the application database, allowing only the software system itself to access the database, or perhaps, a system administrator. In this manner, all access to the application system data is controlled by the application.
One reason that security is channeled away from the DBMS and localized within the business application is that the security functionality of a typical DBMS is often unsuited to handle application specific security requirements. For example, Microsoft SQL Server, a DBMS, provides protection of data to the table level only. Many business applications, such as Microsoft CRM, may require specific row-level protection. In row-level security, result sets are returned with hidden or withheld data rows based on a user's role and privileges. CRM systems such as Microsoft CRM commonly perform this row-level security through the application software either using a general software executable or programmatically through application programming interfaces (“APIs”).
Another reason that many independent software vendors do not want to utilize DBMS level security is that this may require vendor specific design considerations and support for a particular DBMS. This would make cross-compatibility of the software more difficult to implement. In a system in which database security is channeled through the application software itself, there would be much less consideration for the specific DBMS being used with an application.
While this common security system makes it convenient for CRM system designers to implement localized security, there is often a desire or need to perform analysis on the data stored in an application database that the application itself is not suited, or designed, to perform. In the example of a CRM system, such as Microsoft CRM, there may be a desire to analyze customer data for trends, marketing patterns, demand statistics, budgeting considerations, operating considerations, etc., that the CRM system is not designed to perform. Moreover, there is also no convenient way of sharing Microsoft CRM data with other related business applications, such as enterprise resource planning (“ERP”) applications.
Under the existing security model, one option for providing access to the CRM data is to design an interface to the CRM system for extracting necessary data through the CRM system. This can be done by providing APIs to a user to retrieve the data via the CRM system. However, depending on the CRM system, this procedure can be excruciatingly time consuming and complex, as one would need to be adept at programming code to communicate through the application interface. This approach is not a process many data analysts would be suited to perform.
Many applications, including the Microsoft suite of office products, e.g. Microsoft Word, Microsoft Excel, Microsoft PowerPoint, etc., are able to access any DBMS supporting SQL and ODBC. Thus, another more convenient option for providing access to a Microsoft CRM database is to open the database for access to a group of users via the DBMS. However, as mentioned above, a DBMS usually only allows protection down to the table level and does not allow for micro-level protection of row specific information in the tables. A particular business may not want data analysts to see all the row data but only a subset of the rows. If this option were to be implemented, additional business process changes may need to be made in terms of changing employee business roles and creating new business roles, something that many independent software vendors (“ISVs”) would not like to burden consumers with. Moreover allowing an open database connection would increase the risk of corruption of application data which could greatly harm a business. While opening the database to a system administrator would be reasonable, opening a database for full access to a group of data analysts creates problems in security that would make a database such as a CRM database susceptible to compromise.
Therefore, there is a need for an improved method and system of accessing data in a secured application database via the DBMS without compromising the security intentions of the secured application.